How to write test cases effectively: Example and Template

This article talks about a couple of best practices for test case writing. How to write test steps right, and save time with reusable test cases. Don’t feel that is simple! He makes errors and then finds out it himself sometimes as well. QA expert shares his experience by adding handy test case template for you at the end.

Svyatoslav – working as the QA engineer for almost seven years. Worked on different projects – virtual desktop infrastructure, web testing related to data audit and varied mobile testing. Also, he was working with SQL staff and REST API a lot. Moreover, our team know Svyatoslav as a passionate testing coach and QA meetup speaker. He loves teaching people who want to become QA very much. Dogs, hiking, and numismatics are his lovely hobbies. Will free to reach Svyatoslav to barter or sell some coins. He is happy to add new ones to his collection 👏

🔗 Email, Instagram, Linkedin

Svyatoslav Dyuhanchuk

Every QA knows about the test case. This is a document that chases us the whole carrier life. However, why do we need this? Why does it so important for us. How to write test cases correctly. Let’s find out 👀

Table of contents

Test case: what is it?

A test case is a set of actions performed on a system to determine if it satisfies software requirements and functions correctly. ISTQB glossary determines a test case a little bit other.

The purpose of a test case is to determine if different features within a system are performing as expected and to confirm that the system satisfies all related standards, guidelines, and customer requirements. The process of writing a test case can also help reveal errors or defects within the system. Additionally, test cases play a crucial role in manual testing, providing a structured approach to validate system functionality and ensuring comprehensive coverage of software features.

Why do we need a test case?

Test cases define what must be done to test a system, including the steps executed in the system, the input data values that are entered into the system, and the expected results of test case execution.

The benefits of an effective test case include:

  • Reusable test cases.
  • Confirmation that the software satisfies end-user requirements.
  • Improved quality of software and user experience.
  • More satisfied customers will increase company profits.

Process of Creation Test Cases

Test management system

Before creating a test case, we need to identify the best test management system for the project. There are some requirements that need to be checked:

  • Pay/ free – it depends on the budget of the project.
  • Integration with other systems. It would be great if TMS could be integrated with JIRA, Git, Trello, etc.
  • Formatting. It’s also very important how we can edit, save, export, and import functionalities. Also, we need to look through the metrics as well.
  • Support for various test cases. The system should offer robust support for a range of test cases, encompassing manual testing, automated, and performance-based test scenarios, to accommodate diverse software testing needs.

Test design technqiues

For quickly and effectively authoring test cases, it’s important to utilize test design techniques. For instance, when considering how to write test cases, you might employ methods such as:

  • equivalence partitioning and boundary values for input fields
  • decision table for testing different choices
  • state transition for understanding the workflow of the project
  • pairwise testing for testing a lot of combinations
  • a use case for software testing functionalities as a user
  • exploratory testing for more understanding project and do logical steps,
  • error guessing for finding quickly issues which you could definitely be there by our suggesting

There is a lot, but each can help you write a test case easily and quickly

Also read to this subject:

Test case attributes

A lot of TMS (test management system) has different attributes of test cases. However, we have the main which are used in each system. For, example:

  • Test summary. A title that describes the functionality or feature that the test is verifying.
  • Test ID. Typically a numeric or alphanumeric identifier that QA engineers and software testers use to group test cases into test suites. Usually, creating automatically
  • Description. This component describes what the test intends to verify in one to two sentences. Sometimes we ignore it because we write everything in the Test summary
  • References. Links to user stories, design specifications, or requirements that the test is expected to verify.
  • Prerequisites or preconditions – necessary for the tester QA engineer to perform the test.
  • Test setup. This component identifies what the test case needs to run correctly, such as app version, operation system, date and time requirements, and security specifications. It will be chosen when you select test cycle or test run
  • Test steps. Detailed descriptions of the sequential actions that must be taken to complete the test.
  • Expected results. An outline of how the system should respond to each test step.

Test execution

After test cases are written, we can execute them. But before this, we need to put our test in the test cycle for running them. Usually, we put in test cycle: which functionality of program we test, environment: browsers, OSs, etc. There can also be some version or build of the software application. It’s crucial at this stage to reflect on how to write test cases efficiently, ensuring they align with the specific functionalities and environments outlined in the test cycle.

Best practices

  • Create unique test cases and avoid irrelevant or duplicate test cases
  • Write test cases that are transparent and straightforward. The title of each test case should be short.
  • Test case steps should be broken into the smallest possible segments to avoid confusion when executing.
  • The steps of test cases should be max ten for avoiding confusion and long read of test cases
  • Sometimes expected result doesn’t need. For example, if we put in test steps some data, there is not necessary to write that “Data is filled in”
  • Keep the end user in mind whenever a test case is created.
  • Test cases should be written in a way that allows others to easily understand them and modify the document when necessary.
  • Each test case should be easily identifiable.

Example of test

In different TMS we have different UIs part and functionalities. For example, in Testomatio, we can reuse even steps for differents test case. Test steps are written in markdown or saved as snippet. For example, we have test case:

Test summary:
Verify responce of inactivating customer

### Steps
*Create customer with "valid email"
*Find out contract
*Use 
"curl --location --request DELETE http://someapi/v1/contracts/216592?deprovision=true'" 
      for making inactive customer

### Expected result
204

👏 Come on! Are you ready to create a test case per a few clicks now? Just copy this test case and move to the next part of our article. You’ll know how to write test cases fast with such reusable elements as built-in test case templates and snippets in the test case management system.

Ready to use reusable test case elements in action🔥

reusable test case elements

📋 R5X Faster with Testomat.io
Unlock your single source of test management for automated tests
Try it for free
insightstesting tool
Follow us